An online synchronized content management system, such as Dropbox™ from Dropbox Inc. of San Francisco, Calif., allows its users to store and synchronize data on a cloud-based storage and across multiple client devices. Such services allow a user to easily share content with others by allowing the user to upload personal files and folders to the content management system and sharing links to those content items with people that the content owner wishes to share with. The link can be an address, such as a uniform resource locator (URL), that points to the location of a shared content item on the network and sometimes enables direct access to that content item. Thus, those who receive the sharing link can download or otherwise access the shared content item by simply interacting with the link.
However, using links or addresses to share content can introduce potential security vulnerabilities. First, user-uploaded content can contain malicious code that may compromise the integrity of the online content management system. Specifically, users may maliciously or unwittingly upload files that are infused with code (e.g., a virus, a Trojan horse, malware, etc.) that is designed to attack the system by undermining the content management system's security infrastructure and surreptitiously destroying, extracting, and/or sabotaging data. The malicious code can also disable or deny part of the service. In addition, the malicious code can exploit or commandeer the system for use that is inconsistent with the system's original design.
Furthermore, allowing the use of links or addresses to share data stored in an online synchronized content management system may have other unintended consequences such as an increased risk of the link leaking to unauthorized users. For example, through the use of an HTTP referrer (also known as “HTTP referer”) header field, the address of the referring page (i.e., the previous webpage from which a link was followed) may be revealed to an entity that receives an HTTP request. Thus, if a sharing link points to a content item that contains another link, and a user clicks on the second link to issue an HTTP request, even if the receiving entity of the HTTP request was not meant to be given access to the content item, the entity may now have ambient authority over that content item simply because the sharing link has now been revealed to the entity.
As an example, Janet, an employee at Company A may want to share with David, her colleague at Company A, a portable document format (PDF) document containing confidential information about their competitor, Company B. The PDF document details Company A's future plans and strategies for competing with Company B's products. One portion of Janet's document lists Company B's product line and contains a direct URL link to Company B's website (e.g., www.company-b.com/products). Janet shares the PDF document with David by uploading the document to an online content management system and giving David a sharing link issued by the online content management system (e.g., myonlinecontent.com/F8GZ3/confidential.pdf). Using his web browser, David navigates to the sharing link and accesses the confidential PDF document inside his web browser. David peruses through the section about Company B's product line and discovers the link to Company B's website conveniently embedded into the PDF document. When David clicks on the link, his web browser sends out an HTTP request to Company B's website to retrieve the appropriate webpage. However, unbeknownst to David, the HTTP request to www.company-b.com contains an HTTP referer header that identifies the sharing link (i.e., myonlinecontent.com/F8GZ3/confidential.pdf) as the referrer. Thus, now that the sharing link is revealed to Company B through its website, Company B can use the link to access Company A's confidential PDF document about Company B. In this example, it was clearly not Janet or David's intention to share the confidential document with their competitor either when Janet shared the document with David or when David clicked on the embedded link to Company B's website. Such an unintended leakage of an address through an HTTP header is sometimes referred to as a “referer leak.”
There exists a need, therefore, to let users of online content management systems to safely share their online content with other users without the fear of accidentally proliferating harmful code or leaking direct links, and thereby the accompanying access privileges, to the content items.